901006 Benthic Event Detector : System Development Life Cycle Document
This page last changed on Jan 20, 2012 by bkieft.

System Development Life Cycle Document For The Benthic Event Detection System












.8


1.  Scope and Methods

1.1.             Acronyms and Abbreviations

AUV- Autonomous Underwater Vehicle

BED - Benthic Event Detector

ROV - Remotely Operated Vehicle

1.2.             Abstract

We propose developing a Benthic Event Detector (BED) to measure the down-canyon movement of the sediments within Monterey Canyon during mass transport events. This project will be structured as a hybrid feasibility-development project whose goal is to determine the feasibility of constructing a self-contained sensor system (the BED) that detects seafloor sediment motion, and to build a prototype unit ideally in the latter half of 2011, if feasibility is adequately demonstrated. The BED will be equipped with a yet-to-be-determined suite of motion sensors (most likely tilt and/or acceleration) and a pressure transducer, and will be buried just below the sediment surface. This unique sensor will aid in evaluating the new hypothesis that sedimentary fill within submarine canyon floors may move downslope as large masses, not primarily in suspension in the water column above the seafloor or as bedload moving over the surface of the seafloor. If it is conclusively demonstrated that substantial subseafloor movements are occurring, this promises to overturn existing paradigms that explain how sediment moves down submarine canyons.

1.3.             Summary of Problem

Multibeam mapping of Monterey Canyon has revealed the existence of crescentshaped bedforms in the axial channel extending from the canyon head (~11 m) down to ~1900 m water depth. AUV multibeam mapping surveys of other submarine canyons along the California continental margin show that these features are characteristic of active submarine canyons. The occurrence of these bedforms has captured the attention of the marine geologic community and the origin of these features is already controversial. Our recent efforts to determine the origin of these bedforms have included monitoring the movement of buried homer beacons, repeated AUV-multibeam mapping surveys, and ROV vibracoring in upper Monterey Canyon. Results obtained so far have clearly demonstrated that the bedforms are generated during brief, energetic sediment transport events that occur a few times each year which are capable of moving boulder-sized objects hundreds of meters down-canyon. What actually happens in these sediment transport events is less clear. The initial assumption, which logically extended from the existing paradigm, was that the wave-like bedforms are produced by suspension and redeposition of sediments during high-energy turbidity events. In contrast, our data suggest that large sections of the canyon floor appear to move in a slump-like fashion during these events, somewhat analogous to movement of ice within a glacier. This new model challenges the turbidity current model and forces us to re-interpret old data and assumptions. At issue is whether the sediment transport events are turbidity currents that exhume material from the canyon floor and carry it either suspended in the water column, as bedload over the seafloor before it is redeposited further down canyon, or as down-canyon translations of large coherent segments of the seafloor. The depth to which the bottom movements penetrate is unknown, but sustained translation of the seafloor down-canyon is a potential mechanism for carving the canyon into its host rock. An instrument buried in the seafloor designed to record motion during the down-canyon sediment movement would aid in discriminating between the turbidity current, bedload, or coherent-slab transport models.

1.4.             Proposed method

The goal of detecting and characterizing sediments motion to be implemented by means of the following principles:

* Benthic Event Detector (BED), a compact, self-contained autonomous motion detection and data transmission system, to be developed in-house.

* BED system to be deployed by embedding on the surface or into the top portion of the sediment layer; alone or potentially in groups.

* In order to record representative motion data, BEDs shell stay attached to the sediment mass. As a variation, BEDs hydrodynamic properties shall be tunable with the goal of mimicking the behavior of representative sediment layer objects.

* During course of deployment BEDs shell transmit motion dynamics of surrounding sediments by means of (TBD) parameters. 

2.  Development

2.1.             User Requirements Specifications


BEDS-0005: The system shall contain a sensor package which can adequately resolve the motion of the BED.

BEDS-0010: The system shall operate in a water depth up to 500 meters.

BEDS-0015: The system shall store collected data onboard.

BEDS-0026: The system shall operate over a temperature range of -3 to 50 degrees Celsius. [-3°C Arctic water; 50 °C deck temperature)].

BEDs-0027: The system shall be able to survive tumbling and potential localized impacts during sediment transport events.

BEDS-0028: The system shall be "ruggedized" to withstand acceleration shocks associated with transport of TBD g. (currently working with engineering department from avalanche transceiver manufacturer to determine if their specs would be reasonable)

BEDS-0029: The system shall be "ruggedized" to withstand vibration of TBD g at TBD Hz. to TBD Hz. (currently working with engineering department from avalanche transceiver manufacturer to determine if their specs would be reasonable)

BEDS-0030: The system shall be functional for at least 12 months. (This meets the limitations of ship time. Previous data also suggests that at least one 'large' event occurs every 12 months.)

BEDS-0032: The system shall communicate and offload data underwater via an acoustic interface (defined in section TBD below) without tethered communications device and without excavation, from the depth of up 3m beneath the sediment. (Excavation is logistically challenging and any tether would alter dynamics of BED.)

BEDS-0033: The system shall be packaged with a CG that favors an upwards pointing acoustic transducer.

BEDS-0034: The system shall have compact core and to have rotational symmetry.

BEDS-0070: The system shall communicate at any package orientation. (conflicting with -0033, 0034)

BEDS-0035: The system shall be packaged to have a default density comparable to the top 3m of sediment - between 1.5 and 1.8 G/CC. (This will keep package from sinking below the depth where data can be retrieved remotely).

BEDS-0037: The system shall be packaged such that its density could be increased to 3 times the default package density so that self-burial can occur (i.e., it can be made more dense).

BEDS-0038: The system shall be packaged with a physical interface allowing it to be deployed stand alone or attached to a larger deployment apparatus in order to change dynamics and/or density.

BEDS-0039: The system shall be designed as small as possible to approximate the natural motion of sediment within the canyon floor.

BEDS-0045: The system shall be deployable from an MBARI ROV.

BEDS-0065: The system shall allow end user to select specific data subsets for offloading.

BEDS-0072: The system shall measure and record data at any package orientation.

BEDS-0075: The system shall timestamp data collected during a sediment transport event with < 1 sec resolution and < 1 min precision over the whole length of the deployment.

BEDS-0080: The system shall include data up to 5 minutes prior to the start of and at least 1 minute after a sediment transport event in the offloadable data set.

BEDS-0090: The system shall allow parameter values associated with sediment transport event detection to be varied over the deployed communications link.

BEDS-0092: The system shall re-evaluate existing data upon change of a sediment transport event detection parameter.

2.2.             System Requirements

BEDS-0025: The system shall limit clock drift to less than 1 minute per year.

BEDS-0025: BEDS BEDS-0025: -0020: The system shall timestamp data from a source synced to an absolute time base shared by other assets in Monterey Bay, such as STEDs, McStar, MARS, MBARI buoys, and/or NOAA buoys.

BEDS-0054: The system shall record orientation in 3 rotational axles with resolution of at least 0.1 degree and at a maximum frequency of 10 Hz.

BEDS-0055: The system shall compute linear motion in 3 linear axles (coordinates, velocity, acceleration) or systemized product (power, amplitudes, etc) to within... TBD

BEDS-0057: The system shall record pressure with resolution of at least 0.016 dbar (16 mm) and at a maximum frequency of 10 Hz. Distinguish between internal data and data to be transmitted?

BEDS-0058: The system shall resolve position to within ... TBD

BEDS-0060: The system shall record in-situ temperature with resolution 0.1 degree C at a maximum frequency of 10 Hz. [for temperature compensation of sensors]. Distinguish between internal data and data to be transmitted?

BEDS-0085: The system shall detect a sediment transport event using a combination of one or more of the following parameters, their static values, and their rate of change.

-         Translation

-         Depth

-         Orientation

Triggering thresholds, rate of change criteria, and weighting parameters are TBD.

BEDS-0095: The system shall allow the data sampling rate to be varied over the deployed communications link.

2.3.Data processing Algorithms

Assuming the discrete nature of the sediment transport events, and to save energy/ bandwidth, the operating algorithm of BED can be split into the following modes of operation:

  Watch cycle:
  1. Bias calibration. Read rotation rates Rx, Ry, Rz, N samples every T time, calculate average values Rxm, Rym, Rzm. To save energy, put sensor to sleep between reads. Calculate Running Average (NN samples). Example: read 20 samples during 50ms, with 1 second period, and calculate 1 min Running Average
  2. Event detection. Compare Rxm, Rym, Rzm to the value of previous reading (or running average). If difference exceeds Tthreshold, initiate Record Cycle
  3. Continue to run Watch Cycle, if condition (2) is not met for (1 minute), stop Recording Cycle
  4. Creep detection. Store average Ax, Ay, Az, and Mx, My, Mz, to detect motion below Threshold
  5. Magnitude recording. Continuous recording of characteristic motion in energy or magnitude units.
  6. Listen for acoustic communication and initiate Data Retrieval Cycle
  


  Recording Cycle:
  1. Read sensor continuously with high data rate (100-200Hz)
  2. Run algorithm to resolve detailed motion (Translation, Rotation, Acceleration, TBD)
  3. Store Motion parameters with low rate (10 Hz?) resolution for retrieval at the later date.
  


  Data Retrieval Cycle:
  1. Establish communication
  2. Determine Data Upload Range
  3. Transmit
  

 




























2.4. 


2.5. Detailed Design


3.  Implementation and Specifications

3.1.             System Specifications

3.2.             Operational Capabilities

3.3.             Limitations


4.  Qualification and Testing

4.1.             Test Plan

4.2.             Test Procedures

4.3.             Test Report

Reference file: TBD

5.  Applicable Documents

BEDs File Formats- September 2011, MBARI Doc #TBD

 

Note: Unless otherwise noted, references to applicable documents are to the latest version published.
Document generated by Confluence on Feb 03, 2026 15:40